feat(db): add experimental db tunnel (MySQL over WebSocket) - #249

… to TLS

The experimental `db tunnel` command now steps its OAuth credential up to a
dedicated hosting.database:tunnel scope in addition to
hosting.paas.deploy:execute, so authority to publish a deployment does not by
itself grant raw database read/write. The scope is declared in the registry
(default off) and presented at the mint call; the edge enforces both scopes.

Because the tunnel forwards bytes without terminating TLS, the command's long
help, its connect hint, and the proposal now steer operators to connect their
MySQL client with TLS enabled (for example --ssl-mode=REQUIRED) so the local
hop is encrypted as well, and note the database may compel it with
require_secure_transport=ON.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

build_tunnel_ws_url mapped `http|ws` to plain `ws`. Nothing can reach that
branch any more, and it is a latent cleartext-downgrade path, so drop it and
admit only `https|wss`.

The agent URL is service-supplied: it comes only from the mint response
(`app.urls.agent`, read verbatim from mgmt-airo), and `--agent-url` was removed
before this shipped. In production the data plane is CLI -> Cloudflare (TLS) ->
v2-ingress-proxy -> agent `:80`, where the plaintext listener sits inside the
cell and is reachable from ingress nodes only; the host in `agentUrl` is always
the Cloudflare-fronted https name. The one consumer of the `http` branch was
agents/scripts/db-tunnel-local.ts, a throwaway harness since deleted from
airo-app-builder.

Nothing validates the scheme upstream either -- the mint response schema is
`agentUrl: z.string()`, trimmed and checked non-empty only -- so a
mis-provisioned or tampered record would have silently put the agent JWT and
every MySQL byte on the wire in the clear (CWE-319). Rejecting instead fails the
run with a clear error before any port is bound. It also makes the CLI's
`rustls-tls-webpki-roots` posture unconditional: a vendored root set does
nothing when the scheme is not `wss` at all.

The `https`->`wss` mapping itself has to stay -- tungstenite's
`into_client_request` accepts only `ws`/`wss`.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Conflict in rust/src/hosting/client.rs: main (godaddy#276, godaddy#278) replaced the
hand-rolled request helpers with the generated `hosting-client` crate, while this
branch had added `send_json_secret_response` -- a variant that withholds the
response body from the `--debug transport` trace so the agent-token mint cannot
log a minted bearer token (DBT-10).

Resolution keeps main's refactor and preserves that redaction:

- Dropped `send_json` / `send_json_secret_response` / `send_json_inner`. After
  the refactor every caller goes through `api()`, `send_patch` or
  `post_empty_json`, so they had no remaining users.
- Kept the `REDACTED_RESPONSE_BODY` marker and moved the redaction onto
  `post_empty_json`, which is the helper `get_agent_token` now needs: split into
  `post_empty_json_inner(path, log_response_body)` behind `post_empty_json` and
  `post_empty_json_secret_response`. `create_deployment` keeps the logging
  variant; only the mint redacts.
- `get_agent_token` now calls `post_empty_json_secret_response`, preserving its
  wire contract (POST, empty JSON body, bearer auth) -- pinned by the unchanged
  `get_agent_token_posts_empty_body_and_returns_url_and_token` test, which still
  passes.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>